With the tremendous growth in the number of DB2 (database) subsystems and production objects requiring Disaster Site Recovery (DSR), the effort to successfully perform recovery testing has become almost unmanageable. Verifying recovery processes and manually executing DSR severely impacts support availability, removing database administrators from their primary production support responsibilities for unacceptable lengths of time.
Recovery processes for each subsystem are typically tested annually. To ensure recovery will perform as expected, database administrators must review all recovery processes for each subsystem prior to each test, verifying that the processes are current with the requirements of the applications, changes to the environment, etc. If upgrades to a DB2 subsystem offer recovery enhancements, all recovery jobs must be manually retrofitted with the changes necessary to take advantage of the enhancements. Since actual resource availability during a DSR test is unknown, attempts to balance recovery workload are “best guess”.
Once verified, the database administrator must manually submit and monitor the recovery jobs during the DSR test to ensure problems are identified and corrected quickly. When recovery of an object is complete, the database administrator must manually search through the job output and record the start and end times for reporting purposes.
What is needed is a flexible process that automatically creates all of the jobs necessary to perform DSR for all applications in a DB2 subsystem.